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Abstract 


Digital Enhanced Cordless Telecommunications 
is a low-power air interface technology that is proposed by the 


(ULE) 


(DECT) Ultra Low Energy (ULE) 


(DECT) Ultra Low Energy 


DECT Forum and is defined and specified by ETSI. 


The DECT air interface technology has been used worldwide in 


communication devices for more than 20 years. 


It has primarily been 


used to carry voice for cordless telephony but has also been deployed 


for data-centric services. 


DECT ULE is a recent addition to the DECT interface primarily 


intended for low-bandwidth, 
devices, smart meters, 


reserved frequency band, 


home automation, 
interface inherits many of the capabilities from DECT, 
from operation that is long-range and interference-free, 
low silicon prices, 


low-power applications such as sensor 


As the DECT ULE 

it benefits 
worldwide- 
There is 


eta, 


and maturity. 


an added value in the ability to communicate with IPv6 over DECT ULE, 
such as for Internet of Things applications. 


This document describes how IPv6 is transported over DECT ULE using 


IPv6 over Low-Power Wireless Personal Area Network 


techniques. 


Mariager, et al. 


Standards Track 


(6LOWPAN) 


[Page 1] 


RFC 8105 IPv6 over DECT ULE May 2017 


Status of This Memo 
This is an Internet Standards Track document. 
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Les 


Introduction 


Digital Enhanced Cordless Telecommunications (DECT) is a standard 
series [EN300.175-part1-7] specified by ETSI, and CAT-iq (Cordless 
Advanced Technology — internet and quality) is a set of product 
certification and interoperability profiles [CAT-iq] defined by DECT 
Forum. DECT Ultra Low Energy (DECT ULE or just ULE) is an air 
interface technology building on the key fundamentals of traditional 
DECT/CAT-iq but with specific changes to significantly reduce the 
power consumption at the expense of data throughput. DECT ULE 
devices with requirements on power consumption, as specified by ETSI 
in [TS102.939-1] and [TS102.939-2], will operate on special power- 
optimized silicon but can connect to a DECT Gateway supporting 
traditional DECT/CAT-iq for cordless telephony and data as well as 
the ULE extensions. 


DECT terminology has two major role definitions: the Portable Part 
(PP) is the power-constrained device while the Fixed Part (FP) is the 
Gateway or base station. This FP may be connected to the Internet. 
An example of a use case for DECT ULE is a home-security sensor 
transmitting small amounts of data (few bytes) at periodic intervals 
through the FP but that is able to wake up upon an external event 
(e.g., a break-in) and communicate with the FP. Another example 
incorporating both DECT ULE and traditional CAT-iq telephony would be 
a pendant (brooch) for the elderly that generally transmits periodic 
status messages to a care provider using very little battery, but in 
the event of an emergency, the elderly person can establish a voice 
connection through the pendant to an alarm service. It is expected 
that DECT ULE will be integrated into many residential gateways, as 
many of these already implement DECT CAT-iq for cordless telephony. 
DECT ULE can be added as a software option for the FP. 


It is desirable to consider IPv6 for DECT ULE devices due to the 


large address space and well-known infrastructure. This document 
describes how IPv6 is used on DECT ULE links to optimize power while 
maintaining the many benefits of IPv6 transmission. [RFC4944], 


[RFC6282], and [RFC6775] specify the transmission of IPv6 over IEEE 
802.15.4. DECT ULE has many characteristics similar to those of IEEE 
802.15.4, but it also has differences. A subset of mechanisms 
defined for transmission of IPv6 over IEEE 802.15.4 can be applied to 
the transmission of IPv6 on DECT ULE links. 


This document specifies how to map IPv6 over DECT ULE inspired by 
[RFC4944], [RFC6282], [RFC6775], and [RFC7668]. 
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1.1. Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


1.2. Terms Used 


6CO 6LOWPAN Context Option [RFC6775] 

6BBR 6loWPAN Backbone Router 

6LBR 6LOWPAN Border Router, as defined in [RFC6775]. 
The DECT Fixed Part has this role. 

6LN 6LOWPAN Node as defined in [RFC6775]. 


The DECT Portable Part has this role 
6LOWPAN IPv6 over Low-Power Wireless Personal Area Network 
AES128 Advanced Encryption Standard with a key size of 128 bits 


API Application Programming Interface 

ARO Address Registration Option [RFC6775] 

CAT-ig Cordless Advanced Technology - internet and quality 
CTD Context Identifier [RFC6775] 

DAC Destination Address Compression 

DAD Duplicate Address Detection [RFC4862] 

DAM Destination Address Mode 

DHCPVv6 Dynamic Host Configuration Protocol for IPv6 [RFC3315] 
DLC Data Link Control 

DSAA2 DECT Standard Authentication Algorithm #2 

DSC DECT Standard Cipher 

DSC2 DECT Standard Cipher #2 

FDMA Freguency-Division Multiple Access 

FP DECT Fixed Part; the Gateway 

GAP Generic Access Profile 

IID Interface Identifier 

IPEI International Portable Equipment Identity; DECT identity 
MAC-48 48-bit global unique MAC address managed by IEEE 
MAC Media Access Control 

MTU Maximum Transmission Unit 

NBMA Non-Broadcast Multi-Access 

ND Neighbor Discovery [RFC4861] [RFC6775] 

PDU Protocol Data Unit 

PHY Physical Layer 

PMID Portable MAC Identity; DECT identity 

PP DECT Portable Part; typically the sensor node (6LN) 
PVC Permanent Virtual Circuit 

RFPI Radio Fixed Part Identity; DECT identity 

SAC Source Address Compression 

SAM Source Address Mode 

TDD Time Division Duplex 
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TDMA Time-Division Multiple Access 

TPUI Temporary Portable User Identity; DECT identity 
UAK User Authentication Key; DECT master security key 
ULA Unique Local Address [RFC4193] 


2. DECT Ultra Low Energy 


DECT ULE is a low-power air interface technology that is designed to 
support both circuit-switched services, such as voice communication, 
and packet-mode data services at a modest data rate. This document 

is only addressing the packet-mode data service of DECT ULE. 


2.1. The DECT ULE Protocol Stack 


The DECT ULE Protocol Stack contains a PHY layer operating at 
frequencies in the 1880 — 1920 MHz frequency band depending on the 
region and uses a symbol rate of 1.152 Mbaud. Radio bearers are 
allocated by use of FDMA/TDMA/TDD techniques. 


In its generic network topology, DECT is defined as a cellular 
network technology. However, the most common configuration is a star 
network with a single FP defining the network with a number of PPs 
attached. The MAC layer supports both traditional DECT circuit mode 
operation, as this is used for services like discovery, pairing, 
security features, etc., and it supports new ULE packet-mode 
operation. The circuit-mode features have been reused from DECT. 


The DECT ULE device can switch to the ULE mode of operation, 
utilizing the new ULE MAC layer features. The DECT ULE Data Link 
Control (DLC) provides multiplexing as well as segmentation and 
reassembly for larger packets from layers above. The DECT ULE layer 
also implements per-message authentication and encryption. The DLC 
layer ensures packet integrity and preserves packet order, but 
delivery is based on best effort. 


The current DECT ULE MAC layer standard supports low-bandwidth data 
broadcast. However, this document is not considering usage of the 
DECT ULE MAC layer broadcast service for IPv6 over DECT ULE. 


In general, communication sessions can be initiated from both the FP 
side and the PP side. Depending on power-down modes employed in the 
PP, latency may occur when initiating sessions from the FP side. MAC 
layer communication can take place using either connection-oriented 
packet transfer with low overhead for short sessions or connection- 
oriented bearers including media reservation. The MAC layer 
autonomously selects the radio-spectrum positions that are available 
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within the band and can rearrange these to avoid interference. The 
MAC layer has built-in retransmission procedures in order to improve 
transmission reliability. 


The DECT ULE device will typically incorporate an Application 
Programming Interface (API), as well as common elements known as 
Generic Access Profiles (GAPs), for enrolling into the network. The 
DECT ULE Stack establishes a Permanent Virtual Circuit (PVC) for the 
application layers and provides support for a range of different 


application protocols. The application protocol is negotiated 
between the PP and FP when the PVC communication service is 
established. [TS102.939-1] defines this negotiation and specifies an 


Application Protocol Identifier set to 0x06 for 6LOWPAN. This 
document defines the behavior of that application protocol. 


AZ tt + 
| Application Layers | 
4---------------------------------------- + 
| Generic Access | ULE Profile | 
| Profile | | 
4---------------------------------------- + 
| DECT/Service API | ULE Data API | 
4+-------------------- 4------------------- + 
| LLME | NWK (MM,CC) | | 
+-------------------- +------------------- + 
| DECT DLC | DECT ULE DLC | 
4+-------------------- 4+------------------- + 
| MAC Layer | 
4-------------------- 4+------------------- + 
| PHY Layer | 
4+-------------------- 4------------------- + 
(C-plane) (U-plane) 


Figure 1: DECT ULE Protocol Stack 


Figure 1 shows the DECT ULE Stack divided into the Control Plane 
(C-plane) and User Data Plane (U-plane), to the left and to the 
right, respectively. The shown entities in the Stack are the 
Physical Layer (PHY), Media Access Control (MAC) Layer, Data Link 
Control (DLC) Layer, and Network Layer (NWK), along with following 
subcomponents: Lower-Layer Management Entity (LLME), Mobility 
Management (MM), and Call Control (CC). Above there are the typical 
Application Programmers Interface (API) and application-profile- 
specific layers. 
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2.2. Link Layer Roles and Topology 


An FP is assumed to be less constrained than a PP. Hence, in the 
primary scenario, the FP and PP will act as 6LBR and a 6LN, 
respectively. This document only addresses this primary scenario, 
and all other scenarios with different roles of an FP and PP are out 
of scope. 


In DECT ULE, at the link layer, the communication only takes place 
between an FP and a PP. An FP is able to handle multiple 
simultaneous connections with a number of PPs. Hence, in a DECT ULE 
network using IPv6, a radio hop is equivalent to an IPv6 link and 
vice versa (see Section 3.3). 


[DECT ULE PP]----- \ fesse [DECT ULE PP] 
\ / 

[DECT ULE PP]------- +[DECT ULE FP]+------- [DECT ULE PP] 
/ \ 

[DECT ULE PP]----- / N===>= [DECT ULE PP] 


Figure 2: DECT ULE Star Topology 


A significant difference between IEEE 802.15.4 and DECT ULE is that 
the former supports both star and mesh topology (and requires a 
routing protocol), whereas DECT ULE in its primary configuration does 
not support the formation of multihop networks at the link layer. In 
consequence, the mesh header defined in [RFC4944] is not used in DECT 
ULE networks. 


DECT ULE repeaters are considered to operate transparently in the 
DECT protocol domain and are outside the scope of this document. 


2.3. Addressing Model 


Each DECT PP is assigned an IPEI during manufacturing. This identity 
has the size of 40 bits and is globally unique within DECT addressing 
space and can be used to constitute the MAC address used to derive 
the IID for link-local address. 


During a DECT location registration procedure, the FP assigns a 
20-bit TPUI to a PP. The FP creates a unique mapping between the 
assigned TPUI and the IPEI of each PP. This TPUI is used for 
addressing (Layer 2) in messages between the FP and PP. Although the 
TPUI is temporary by definition, many implementations assign the same 
value repeatedly to any given PP, hence it seems not suitable for 
construction of the IID (see [RFC8065]). 
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Each DECT FP is assigned an RFPI during manufacturing. This identity 
has the size of 40 bits and is globally unique within DECT addressing 
space and can be used to constitute the MAC address used to derive 
the IID for link-local address. 


Optionally, each DECT PP and DECT FP can be assigned a unique (IEEE) 
MAC-48 address in addition to the DECT identities to be used by the 
6LOWPAN. During the address registration of non-link-local addresses 
as specified by this document, the FP and PP can use such MAC-48 to 
construct the IID. However, as these addresses are considered as 
being permanent, such a scheme is NOT RECOMMENDED as per [RFC8065]. 


2.4. MTU Considerations 


Ideally, the DECT ULE FP and PP may generate data that fits into a 
single MAC layer packet (38 octets) for periodically transferred 
information, depending on application. However, IP packets may be 
much larger. The DECT ULE DLC procedures natively support 
segmentation and reassembly and provide any MTU size below 65536 
octets. The default MTU size defined in DECT ULE [TS102.939-1] is 
500 octets. In order to support complete IPv6 packets, the DLC layer 
of DECT ULE SHALL, per this specification, be configured with an MTU 
size of 1280 octets, hence [RFC4944] fragmentation/reassembly is not 
required. 


It is important to realize that the usage of larger packets will be 
at the expense of battery life, as a large packet inside the DECT ULE 
Stack will be fragmented into several or many MAC layer packets, each 
consuming power to transmit/receive. The increased MTU size does not 
change the MAC layer packet and PDU size. 


2.5. Additional Considerations 


The DECT ULE standard allows the PP to be DECT-registered (bound) to 
multiple FP and to roam between them. These FP and their 6LBR 
functionalities can operate either individually or connected through 
a Backbone Router as per [BACKBONE-ROUTER]. 


3. Specification of IPv6 over DECT ULE 


Before any IP-layer communications can take place over DECT ULE, 
DECT-ULE-enabled nodes such as 6LNs and 6LBRs have to find each other 
and establish a suitable link layer connection. The obtain-access- 
rights registration and location registration procedures are 
documented by ETSI in the specifications [EN300.175-part1-7], 
[TS102.939-1], and [TS102.939-2]. 
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DECT ULE technology sets strict requirements for low power 
consumption and, thus, limits the allowed protocol overhead. 6LOWPAN 
standards [RFC4944], [RFC6775], and [RFC6282] provide useful 
functionality for reducing overhead that can be applied to DECT ULE. 
This functionality comprises link-local IPv6 addresses and stateless 
IPv6 address autoconfiguration, Neighbor Discovery, and header 
compression. 


The ULE 6LOWPAN adaptation layer can run directly on this U-plane DLC 
layer. Figure 3 illustrates an IPv6 over DECT ULE Stack. 


Because DECT ULE in its primary configuration does not support the 
formation of multihop networks at the link layer, the mesh header 
defined in [RFC4944] for mesh under routing MUST NOT be used. In 
addition, the role of a 6LOWPAN Router (6LR) is not defined per this 
specification. 


3.1. Protocol Stack 


In order to enable data transmission over DECT ULE, a Permanent 
Virtual Circuit (PVC) has to be configured and opened between the FP 
and PP. This is done by setting up a DECT service call between the 
PP and FP. In the DECT protocol domain, the PP SHALL specify the 
<<IWU-ATTRIBUTES>> in a service-change (other) message before sending 
a service-change (resume) message as defined in [TS102.939-1]. The 
<<IWU-ATTRIBUTES>> SHALL set the ULE Application Protocol Identifier 
to 0x06 and the MTU size to 1280 octets or larger. The FP sends a 
service-change-accept (resume) that MUST contain a valid paging 
descriptor. The PP MUST listen to paging messages from the FP 
according to the information in the received paging descriptor. 
Following this, transmission of IPv6 packets can start. 


4------------------- + 
| UDP/TCP/other | 
4------------------- + 
| IPv6 | 
4------------------- + 
|6LOWPAN adapted to | 
| DECT ULE 

4------------------- + 
| DECT ULE DLC | 
4------------------- + 
| DECT ULE MAC | 
4------------------- + 
| DECT ULE PHY | 
+------------------- + 


Figure 3: IPv6 over DECT ULE Stack 
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3.2. Link Model 


The general model is that IPv6 is Layer 3 and DECT ULE MAC and DECT 
ULE DLC are Layer 2. DECT ULE already implements fragmentation and 
reassembly functionality; hence, the fragmentation and reassembly 
function described in [RFC4944] MUST NOT be used. 


After the FPs and PPs have connected at the DECT ULE level, the link 
can be considered up and IPv6 address configuration and transmission 
can begin. The 6LBR ensures address collisions do not occur. 


Per this specification, the IPv6 header compression format specified 
in [RFC6282] MUST be used. The IPv6 payload length can be derived 
from the ULE DLC packet length. The possibly elided IPv6 address can 
be reconstructed from the lower layer address (see Section 3.2.4). 


Due to the DECT ULE star topology (see Section 2.2), each PP has a 
separate link to the FP; thus, the PPs cannot directly hear one 
another and cannot talk to one another. As discussed in [RFC4903], 
conventional usage of IPv6 anticipates IPv6 subnets spanning a single 
link at the link layer. In order to avoid the complexity of 
implementing a separate subnet for each DECT ULE link, a Multi-Link 
Subnet model [RFC4903] has been chosen, specifically Non-Broadcast 
Multi-Access (NBMA) at Layer 2. Because of this, link-local 
multicast communications can happen only within a single DECT ULE 
connection; thus, 6LN-to-6LN communications using link-local 
addresses are not possible. 6LNs connected to the same 6LBR have to 
communicate with each other utilizing the shared prefix used on the 
subnet. The 6LBR forwards packets sent by one 6LN to another. 


3.2.1. Stateless Address Autoconfiguration 


At network interface initialization, both 6LN and 6LBR SHALL generate 
and assign IPv6 link-local addresses to the DECT ULE network 
interfaces [RFC4862] based on the DECT device addresses (see 

Section 2.3) that were used for establishing the underlying DECT ULE 
connection. 


The DECT device addresses IPEI and RFPI MUST be used to derive the 
IPv6 link-local 64-bit Interface Identifiers (IIDs) for 6LN and 6LBR, 
respectively. 


The rule for deriving IIDs from DECT device addresses is as follows: 
the DECT device addresses that consist of 40 bits each MUST be 
expanded with leading zero bits to form 48-bit intermediate 
addresses. The most significant bit in this newly formed 48-bit 
intermediate address is set to one for addresses derived from the 
RFPI and set to zero for addresses derived from the IPEI. 64-bit IIDs 
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are derived from these intermediate 48-bit addresses following the 
guidance in Appendix A of [RFC4291]. However, because DECT and IEEE 
address spaces are different, this intermediate address cannot be 
considered to be unique within an IEEE address space. In the derived 
IIDs, the Universal/Local (U/L) bit (7th bit) will be zero, which 
indicates that derived IIDs are not globally unique, see [RFC7136]. 
For example, from RFPI=11.22.33.44.55, the derived IID is 
80:11:22:ff:fe:33:44:55; from IPEI=01.23.45.67.89, the derived IID is 
00:01:23:ff:fe: 45:67:89. 


Global uniqueness of an IID in link-local addresses is not required 
as they should never be leaked outside the subnet domain. 


As defined in [RFC4291], the IPv6 link-local address is formed by 
appending the IID to the prefix FE80::/64, as shown in Figure 4. 


[1111111010 zeros | Interface Identifier 
Fee 4----------------- Fennen + 


Figure 4: IPv6 Link-Local Address in DECT ULE 
A 6LN MUST join the all-nodes multicast address. 


After link-local address configuration, 6LN sends Router Solicitation 
messages as described in Section 6.3.7 of [RFC4861] and Section 5.3 
of [RFC6775]. 


For non-link-local addresses, 6LNs SHOULD NOT be configured to use 
IIDs derived from a MAC-48 device address or DECT device addresses. 
Alternative schemes such as Cryptographically Generated Addresses 
(CGAs) [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses 
(HBAS) [RFC5535], DHCPv6 [RFC3315], or static, semantically opaque 
addresses [RFC7217] SHOULD be used by default. See also [RFC8065] 
for guidance of needed entropy in IIDs and the recommended lifetime 
of used IIDs. When generated IIDs are not globally unique, Duplicate 
Address Detection (DAD) [RFC4862] MUST be used. In situations where 
deployment constraints require the device’s address to be embedded in 
the IID, the 6LN MAY form a 64-bit IID by utilizing the MAC-48 device 
address or DECT device addresses. The non-link-local addresses that 
a 6LN generates MUST be registered with 6LBR as described in 

Section 3.2.2. 


The means for a 6LBR to obtain an IPv6 prefix for numbering the DECT 
ULE network is out of scope of this document, but a prefix can be, 
for example, assigned via DHCPv6 Prefix Delegation [RFC3633] or using 
IPv6 Unicast Unique Local Addresses (ULAs) [RFC4193]. Due to the 
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link model of the DECT ULE, the 6LBR MUST set the "on-link" (L) flag 
to zero in the Prefix Information Option [RFC4861]. This will cause 
6LNs to always send packets to the 6LBR, including the case when the 
destination is another 6LN using the same prefix. 


.2. Neighbor Discovery 


"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 
Personal Area Networks (6LoWPANs)" [RFC6775] describes the Neighbor 
Discovery approach as adapted for use in several 6LOWPAN topologies, 
including the mesh topology. As DECT ULE does not support mesh 
networks, only those aspects of [RFC6775] that apply to star topology 
are considered. 


The following aspects of the Neighbor Discovery optimizations 
[RFC6775] are applicable to DECT ULE 6LNs: 


1. For sending Router Solicitations and processing Router 
Advertisements the DECT ULE 6LNs MUST, respectively, follow 
Sections 5.3 and 5.4 of the [RFC6775]. 


2. A DECT ULE 6LN MUST NOT register its link-local address. Because 
the IIDs used in link-local addresses are derived from DECT 
addresses, there will always exist a unique mapping between link- 
local and Layer 2 addresses. 


3. A DECT ULE 6LN MUST register its non-link-local addresses with 
the 6LBR by sending a Neighbor Solicitation (NS) message with the 
Address Registration Option (ARO) and process the Neighbor 
Advertisement (NA) accordingly. The NS with the ARO option MUST 
be sent irrespective of the method used to generate the IID. 


3. Unicast and Multicast Address Mapping 


The DECT MAC layer broadcast service is considered inadequate for IP 
multicast because it does not support the MTU size required by IPv6. 


Hence, traffic is always unicast between two DECT ULE nodes. Even in 
the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot 
do a multicast to all the connected 6LNs. If the 6LBR needs to send 
a multicast packet to all its 6LNs, it has to replicate the packet 
and unicast it on each link. However, this may not be energy 
efficient and particular care should be taken if the FP is battery- 
powered. To further conserve power, the 6LBR MUST keep track of 
multicast listeners at DECT ULE link-level granularity, and it MUST 
NOT forward multicast packets to 6LNs that have not registered for 
multicast groups the packets belong to. In the opposite direction, a 
6LN can only transmit data to or through the 6LBR. Hence, when a 6LN 
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needs to transmit an IPv6 multicast packet, the 6LN will unicast the 
corresponding DECT ULE packet to the 6LBR. The 6LBR will then 
forward the multicast packet to other 6LNs. 


3.2.4. Header Compression 


As defined in [RFC6282], which specifies the compression format for 
IPv6 datagrams on top of IEEE 802.15.4, header compression is 
REQUIRED in this document as the basis for IPv6 header compression on 
top of DECT ULE. All headers MUST be compressed according to 
encoding formats as described in [RFC6282]. The DECT ULE’s star 
topology structure, ARO and 6CO, can be exploited in order to provide 
a mechanism for address compression. The following text describes 
the principles of IPv6 address compression on top of DECT ULE. 


3.2.4.1. Link-Local Header Compression 


In a link-local communication terminated at 6LN and 6LBR, both the 
IPv6 source and destination addresses MUST be elided since the used 
IIDs map uniquely into the DECT link end-point addresses. A 6LN or 
6LBR that receives a PDU containing an IPv6 packet can infer the 
corresponding IPv6 source address. For the unicast type of 
communication considered in this paragraph, the following settings 
MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11, 
DAC=0, and DAM=11. 


3.2.4.2. Non-link-local Header Compression 


To enable efficient header compression, the 6LBR MUST include the 
6LOWPAN Context Option (6CO) [RFC6775] for all prefixes the 6LBR 

advertises in Router Advertisements for use in stateless address 

autoconfiguration. 


When a 6LN transmits an IPv6 packet to a destination using global 
unicast IPv6 addresses, if a context is defined for the prefix of the 
6LNs global IPv6 address, the 6LN MUST indicate this context in the 
corresponding source fields of the compressed IPv6 header as per 
Section 3.1 of [RFC6282] and MUST fully elide the latest registered 
IPv6 source address. For this, the 6LN MUST use the following 
settings in the IPv6 compressed header: CID=1, SAC=1, and SAM=11. In 
this case, the 6LBR can infer the elided IPv6 source address since 1) 
the 6LBR has previously assigned the prefix to the 6LNs and 2) the 
6LBR maintains a Neighbor Cache that relates the device address and 
the IID of the corresponding PP. If a context is defined for the 
IPv6 destination address, the 6LN MUST also indicate this context in 
the corresponding destination fields of the compressed IPv6 header 
and MUST elide the prefix of the destination IPv6 address. For this, 
the 6LN MUST set the DAM field of the compressed IPv6 header as 
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CID=1, DAC=1, and DAM=01 or DAM=11. Note that when a context is 
defined for the IPv6 destination address, the 6LBR can infer the 
elided destination prefix by using the context. 


When a 6LBR receives an IPv6 packet having a global unicast IPv6 
address and the destination of the packet is a 6LN, if a context is 
defined for the prefix of the 6LN’s global IPv6 address, the 6LBR 
MUST indicate this context in the corresponding destination fields of 
the compressed IPv6 header and MUST fully elide the IPv6 destination 
address of the packet if the destination address is the latest 
registered by the 6LN for the indicated context. For this, the 6LBR 
MUST set the DAM field of the IPv6 compressed header as DAM=11. CID 
and DAC MUST be set to CID=1 and DAC=1. If a context is defined for 
the prefix of the IPv6 source address, the 6LBR MUST indicate this 
context in the source fields of the compressed IPv6 header and MUST 
elide that prefix as well. For this, the 6LBR MUST set the SAM field 
of the IPv6 compressed header as CID=1, SAC=1, and SAM=01 or SAM=11. 


3.3. Subnets and Internet Connectivity Scenarios 


In the DECT ULE star topology (see Section 2.2), each PP has a 
separate link to the FP, and the FP acts as an IPv6 router rather 
than a link layer switch. A Multi-Link Subnet model [RFC4903] has 
been chosen, specifically Non-Broadcast Multi-Access (NBMA) at Layer 
2, as is further illustrated in Figure 5. The 6LBR forwards packets 
sent by one 6LN to another. In a typical scenario, the DECT ULE 
network is connected to the Internet as shown in the Figure 5. In 
this scenario, the DECT ULE network is deployed as one subnet using 
one /64 IPv6 prefix. The 6LBR acts as a router and forwards packets 
between 6LNs to and from Internet. 


6LN 
\ 
\ / \ 
6LN ---- 6LBR ------ | Internet | 
/ \ / 
/ 
6LN 
<-- One subnet --> 
<-- DECT ULE --> 


Figure 5: DECT ULE Network Connected to the Internet 


In some scenarios, the DECT ULE network may transiently or 
permanently be an isolated network as shown in the Figure 6. In this 
case, the whole DECT ULE network consists of a single subnet with 
multiple links, where 6LBR is routing packets between 6LNs. 


Mariager, et al. Standards Track [Page 15] 


RFC 8105 


IPv6 over DECT ULE May 2017 


6LN 6LN 
\ / 
\ / 
6LN --- 6LBR --- 6LN 
/ \ 
/ \ 
6LN 6LN 
<---- One subnet ----> 
<------ DECT ULE ----- > 
Figure 6: Isolated DECT ULE Network 


In the isolated network scenario, communications between 6LN and 6LBR 
can use IPv6 link-local methodology, but for communications between 
different PP, the FP has to act as 6LBR, number the network with a 
ULA prefix [RFC4193], and route packets between the PP. 


In other more advanced systems scenarios with multiple FPs and 6LBR, 
each DECT ULE FP constitutes a wireless cell. The network can be 
configured as a Multi-Link Subnet in which the 6LN can operate within 
the same /64 subnet prefix in multiple cells as shown in the 


Figure 7. The FPs in such a scenario should behave as Backbone 
Routers (6BBR) as defined in [BACKBONE-ROUTER]. 
/ \ 
| Internet | 
\ / 
6BBR/ | 6BBR/ 
6LN ---- 6LBR ------- tao 6LBR ---- 6LN 
/ \ fn eN 
Poo J \ 
6LN 6LN 6LN 6LN 
a esses One Subnet. :=2225===22=2==22%2 


<-- DECT ULE Cell 


--> 


<-- DECT ULE Cell 


--> 


Figure 7: Multiple DECT ULE Cells in a Single Multi-link Subnet 
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4. 


IANA Considerations 
This document does not require any IANA actions. 
Security Considerations 


The secure transmission of circuit mode services in DECT is based on 
the DSAA2 and DSC/DSC2 specifications developed by ETSI Technical 
Committee (TC) DECT and the ETSI Security Algorithms Group of Experts 
(SAGE). 


DECT ULE communications are secured at the link layer (DLC) by 
encryption and per-message authentication through CCM (Counter with 
Cipher Block Chaining Message Authentication Code (CBC-MAC)) mode 
similar to [RFC3610]. The underlying algorithm for providing 
encryption and authentication is AES128. 


The DECT ULE pairing procedure generates a master User Authentication 
Key (UAK). During the location registration procedure, or when the 
permanent virtual circuits are established, the session security keys 
are generated. Both the master authentication key and session 
security keys are generated by use of the DSAA2 algorithm 
[EN300.175-part1-7], which uses AES128 as the underlying algorithm. 
Session security keys may be renewed regularly. The generated 
security keys (UAK and session security keys) are individual for each 
FP-PP binding; hence, all PPs in a system have different security 
keys. DECT ULE PPs do not use any shared encryption key. 


Even though DECT ULE offers link layer security, it is still 
recommended to use secure transport or application protocols above 
6LOWPAN. 


From the privacy point of view, the IPv6 link-local address 
configuration described in Section 3.2.1 only reveals information 
about the 6LN to the 6LBR that the 6LBR already knows from the link 
layer connection. For non-link-local IPv6 addresses, by default, a 
6LN SHOULD use a randomly generated IID, for example, as discussed in 
[RFC8064], or use alternative schemes such as Cryptographically 
Generated Addresses (CGAs) [RFC3972], privacy extensions [RFC4941], 
Hash-Based Addresses (HBAs, [RFC5535]), or static, semantically 
opaque addresses [RFC7217]. 
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6. ETSI Considerations 


ETSI is standardizing a list of known application-layer protocols 
that can use the DECT ULE permanent virtual circuit packet data 
service. Each protocol is identified by a unique known identifier, 
which is exchanged in the service-change procedure as defined in 
[TS102.939-1]. The IPv6/6LoWPAN as described in this document is 
considered to be an application-layer protocol on top of DECT ULE. 
In order to provide interoperability between 6LOWPAN / DECT ULE 
devices, a common protocol identifier for 6LOWPAN is standardized by 
ETSI. 


The ETSI DECT ULE Application Protocol Identifier is set to 0x06 for 
6LOWPAN [TS102.939-1]. 
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